In communication networks, it is known to provide mechanisms for authenticating a subscriber. In mobile communication networks as specified by 3GPP (3rd Generation Partnership Project), it is for example known to base such mechanisms on associating a user equipment (UE), e.g., a mobile phone, with a SIM (Subscriber Identity Module). The SIM typically contains identity and security information which corresponds to identity and security information stored in the mobile communication network, e.g., in a HSS (Home Subscriber Server) or similar subscriber database. Such identity and security information is typically only accessible to network nodes operated by an operator the subscriber is subscribed to. For other network nodes access to the identity and security information is typically limited for security and privacy reasons. These mechanisms thus primarily aim at authenticating the subscriber within the communication network of the operator the subscriber is subscribed to.
Further, it is known to utilize such mechanism for authenticating the subscriber within the communication network also for authentication with respect to other services, e.g., 3rd party network services not under control of the operator of the communication network. An example of a corresponding technology is the Generic Bootstrapping Architecture (GBA) as specified in 3GPP TS 33.220 V12.3.0 (2014 June).
The GBA technology provides a Bootstrapping Server Function (BSF) which typically is controlled by the operator of the mobile communication network. The BSF is connected to the operator's HSS and can be accessed by a 3rd party offering a network service to a subscriber of the mobile communication network, in particular by a Network Application Function (NAF) operated by the 3rd party. The BSF protects the HSS from direct access by the 3rd party. The NAF authenticates the subscriber's UE with respect to messages from the subscriber's UE. Typically, these messages are generated by a certain application running on the UE to allow access to the offered network service, and the NAF authenticates these messages for the application. The NAF may thus act as a gatekeeper for the application, typically only allowing those messages to pass which could be authenticated, i.e., for which it could be verified that they originated from the subscriber's UE. These messages are typically based on the Hypertext Transfer Protocol (HTTP) and related web technologies, but other protocols or message types could be used as well.
In a typical GBA authentication procedure, when he UE first attempts to access the network service via the NAF by sending a HTTP request, the NAF indicates to the UE that GBA authentication is required by rejecting the request. The UE may then proceed to perform a GBA bootstrapping authentication procedure with the BSF. The bootstrapping authentication procedure with the BSF involves that the UE and the BSF first establish a mutual authentication between themselves first. On the UE side, the mutual authentication makes use of identity and security information stored in the SIM. On the BSF side, the mutual authentication makes use of identity and security information the BSF obtains from the HSS. The mutual authentication is performed by executing cryptographic algorithms both in the UE, probably with the help of the SIM, and the BSF. Based on the cryptographic algorithms, the UE and the BSF also agree on generic cryptographic key material, referred to as Ks. From this generic key material, the UE and the BSF derive further cryptographic key material, referred to as Ks_NAF. The Ks_NAF key material is then used by the UE and the NAF for message authentication when the UE again tries to access the network service via the NAF. The UE confirms authenticity of the message by associating it with authentication information based on the Ks_NAF key material, e.g., by adding authentication information derived via cryptographic algorithms from the Ks_NAF key material and an authentication challenge previously received in response to the failed attempt to access the network service.
Upon receiving the message, the NAF contacts the BSF to obtain the Ks_NAF key material from the BSF. Together with the Ks_NAF key material the BSF may optionally also provide an IP Multimedia Private Identity (IMPI) to the NAF. Based on the Ks_NAF key material and by performing corresponding algorithms as performed by the UE when authenticating the message the NAF can authenticate the message, i.e., verify authenticity of the message from the UE.
In the GBA authentication procedure, it is possible to keep anonymity of the UE with respect to the NAF and the 3rd party operating the NAF. In this case, the NAF and the 3rd party offering the network service would be aware that the subscriber is authenticated, but have no information about the subscriber's identity. This allows providing the network service in an anonymized manner, while still ensuring that the subscriber is actually entitled to use the network service. To achieve anonymity, the bootstrapping authentication procedure may be performed in such a way that the above-mentioned option that the BSF provides the IMPI to the NAF is not used. Further, the UE should not reveal the subscriber identity in the messages transmitted towards the NAF. This for example involves, that the UE does not send a “X-3GPP-Intended-Identity” HTTP header using its real identity. It should either refrain from sending that header or assume an unrelated alias. Of course, the UE should also refrain from sending any other kind of identifying information as part of the application protocol, e.g., a user name which can be traced back to the subscriber identity.
However, when providing the network service in an anonymized manner as outlined above, there is no straightforward way for the provider of the network service to charge the subscriber for usage of the network service: Because the service provide cannot identify the subscriber, the service provider is not able to pinpoint charges to the subscriber. While the BSF is aware of the identity of the subscriber, it is in turn not aware of the subscriber's usage of the network service. The BSF merely knows that a GBA authentication procedure was performed for the subscriber. However, this information, even if provided to the 3rd party service provider, may be insufficient for charging since it does not indicate that the subscriber actually used the network service or to what extent the network service was used, e.g., in terms of duration, data volume, or service level.
Accordingly, there is a need for techniques which allow for efficiently performing charging of a network service provided in an anonymized manner.